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(54) System and method for processing customized financial transaction card 



(57) The present invention provides for a system 
and method of performing financial transactions which 
include a financial card 400 that stores pre-selected 
transaction instructions corresponding to one or more 
financial transactions, such as cash withdrawal, or bill 
payment, or the like. These cards are used with one or 
more terminals 101 which read the instructions on the 
card, interpret those instructions and execute the inter- 



preted instructions to conduct one or more of the finan- 
cial transactions. Preferably the terminal after deter- 
mining from the instructions on the card what functions, 
i.e.. financial transactions, are available to the card user, 
displays those options. The user then selects one of the 
financial transactions. The terminal, based on the selec- 
tion and the instructions corresponding to the selected 
function, executes the transaction 
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Description 

The present invention relates to a commercial 
transaction system and method and particularly to a sys- 
tem and method for conducting commercial transac- 5 
tions using financial cards. 

The present system of conducting financial trans- 
actions (i.e.. those which involve a transfer or exchange 
of value or are of a commercial nature) utilizes transac- 
tion terminals that run predefined programs stored in the 10 
terminal to complete a transaction or transactions when 
a financial card is placed in the terminal. One example 
of a transaction terminal is an automatic teller machine 
(ATM). When a customer uses an automatic teller ma- 
chine, the ATM accepts the customer's card when >s 
placed in a designated receptacle and executes a stored 
resident transaction program which interacts with the 
customer and performs selected functions. The pro- 
gram typically allows the customer to select a desired 
service to be performed and/or an amount to be depos- 20 
ited or withdrawn by interacting with a touch-sensitive 
screen or external buttons. The resident program in the 
terminal must be updated periodically to introduce new 
features or services offered to the customer or request- 
ed by the issuer. 25 

Terminal resident transaction programs for financial 
transactions create a number of inconveniences. Indi- 
vidual financial institutions such as banks each issue 
their own financial cards and have their own programs 
which may only support features offered by their own 30 
banks. A specialized feature of one bank, such as a bo- 
nus program for usage, would not be supported by the 
transaction program in the terminal of another bank. To 
insure that an issued card can be used at any terminal, 
each terminal has to be provided with each issuer bank's 35 
transaction programs. 

Moreover many of the terminals have different and 
diverse transaction programs which support varied dis- 
play screens. The variations in the display screen lay- 
outs and differing available options can be confusing to -*o 
customers when different terminals are used at many 
varied locations. The displayed terms used and availa- 
ble by the terminals for interacting with the customer are 
not consistent among all terminals due to the unique op- 
erating programs utilized by each system. -J5 

For example, only some systems may have a 
"Quick Cash" feature which retrieves a predetermined 
amount of cash from the customer's bank account. A 
customer is not guaranteed this option at every terminal. 
Also, when traveling abroad from a customer's home so 
country, the language of the text displayed can make 
transactions difficult to complete. While some terminals 
support multiple languages (i.e., English and Spanish), 
not all languages are programmed into the terminal. 
Presently, the terminals have one pre-set form of inter- ss 
action screen and sequence and do not allow the cus- 
tomer to choose his/her preferred interaction screen. 
As the computer technology advances, more and 



more application programs for new (unctions and serv- 
ices are being created. The primary capability of depos- 
iting and withdrawing money from financial terminals is 
becoming just one of many functions that can be per- 
formed in a transaction. Applications such as automatic 
bill paying, catalog shopping, investment management 
all are in existence today and could soon be added to 
financial terminals. Unfortunately, each application re- 
quires its own executable code or routine to be stored 
within each terminal, creating a significant burden. Also, 
as the number of application routines increases, the size 
of the memory storage needed at the terminal increas- 
es. Moreover, a customer will be forced to go through a 
myriad of menu screens to get to the actual function he 
or she desires. 

In addition, transaction programs that are stored in 
the financial terminals can be programmed in a number 
of different computer languages. Some of these lan- 
guages include "Zontalk" for POS terminals, 8051 
assembly, and 286 assembly languages. Many termi- 
nals are only programmed in one language for the cen- 
tral transaction program and all application sub-pro- 
grams. The terminal then compiles the software pro- 
grams to make an executable file {a binary representa- 
tion of the program created for machine execution) 
which controls the transaction. Each transaction pro- 
gram can be unique but must meet certain software 
specifications in order to properly read financial cards 
presented to the system. The transaction program for 
financial transactions has heretofore always been 
stored in the terminal. 

Other terminals in addition to ATMs can be used at 
least in part as a financial transaction terminal with a 
financial transaction card. These include home personal 
computers, point-of-sale (POS) terminals, and pay 
phones which accept charge cards. All these terminals 
share the problem of the ATM of requiring all the soft- 
ware of the features to be terminal resident, resulting in 
part in a lack of continuity for the customer. 

There are cards containing memory for storing data 
in the prior art. U.S. Patent No 5 : 157,247 issued to 
Takahira and entitled "IC Card" discloses a card with cir- 
cuitry for transmitting and receiving data from an exter- 
nal source, a data memory for storing data, and a data 
processing CPU. Additionally, U.S. Patent No. 
5,225,667 issued to Furuta et al. and entitled "IC Card" 
discloses an IC card containing Random Access Mem- 
ory (RAM). An International ^Application No. WO 
91/16691 by Jones et al. and entitled "value Transfer 
System" discloses a system where electronic purses 
keep individual accounts stored in IC cards. Each IC 
card then changes its balance based upon the price of 
an item purchased and can be replenished at banks. 
Jones et al. shows a benefit of storing data on the card. 

The above referenced IC cards all describe storing 
data elements such as a balance, customer ID. etc. to 
interact with a terminal having a resident transaction 
program. The systems that utilize these cards are there- 
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fore subject to the disadvantages of terminal based op- 
erating systems that are described above. 

Accordingly, it would be beneficial to allow the card 
user and/or card issuer to personalize the terminal dis- 
plays and selection options based on his or her own 
preferences. These personalizations ensure that the 
customer is familiar with the display screens, that the 
screens will be in the proper language for communica- 
tion, and that the options available are only those de- 
sired by the card user or allowed by the card issuer. The 
customization also allows the financial institution that is- 
sued the financial card to assert greater control over the 
customer's financial behavior 

It would also be beneficial to have a financial card 
that contains instructions which carry out these person- 
alized functions, such that all terminals would not have 
to be equipped with all applications desired by all issuing 
banks and all card holders; instead, the issuing bank 
and card holder would dictate the financial transactions 
available as options to the card holder. 

The system according to the present invention is 
defined in claim 1 and the method in claim 1 1 . Preferred 
features of the invention are recited in the dependent 
claims. 

To this end ; there is provided a system and method 
for processing a customized financial transaction card. 
The system and method uses a financial card which 
stores the instructions corresponding to one or more fi- 
nancial transactions. These instructibns are pre-select- 
ed ; meaning that the issuing bank or card holder select, 
prior to card use for a particular transaction, what op- 
tions are available to the user. For instance, options 
such as cash withdrawal, bill payment, or product pur- 
chase, would be available to those users who preselect 
those options prior to use of the card for one of those 
particular transactions. Instructions on the card will al- 
low the user to conduct any one of the pre-selected 
transactions. 

The system and method of the present invention 
further provides for terminals which are programmed to 
read the pre-selected instructions on the card, interpret 
those instructions and execute the interpreted instruc- 
tions to conduct one or more of the financial transac- 
tions. Preferably, the terminals are initially made aware 
that the card contains transaction instructions which 
must be read by the terminal. The terminal reads and 
interprets the instructions on the card and - preferably 
based on a selection made by the user after viewing the 
displayed options available to the user (also dictated by 
the instructions on the card) - the terminal completes 
the transaction. 

In this manner a system and method is provided 
which overcomes the disadvantage of the prior art by 
eliminating the need to provide terminals with countless 
operating procedures and by enabling customized dis- 
plays and options to the transaction card holder. 

Further objects, features and advantages of the in- 
vention will become apparent from the following detailed 



description of one embodiment given by way of example 
and in conjunction with the accompanying figures in 
which: 

s Fig. 1 illustrates a financial terminal in accordance 

with the invention; 

Fig. 2 illustrates a typical menu appearing on a dis- 
play of the terminal in Figure 1; 
Fig. 3 illustrates the internal electronics of the ter- 
io minal in Figure 1 : 

Fig. 4 illustrates a customized financial card storing 
a transaction program in accordance with this in- 
vention; 

Fig. 5 illustrates a customized menu display gener- 
is ated from a transaction program and stored in the 
customized financial card of Fig. 4: and 
Figs. 6A-F illustrate portions of a sample transac- 
tion program written in the customized language 
and stored in the financial card of Fig. 4 wherein: 

20 

6A illustrates the core program: 
6B illustrates the "Quick Cash" subroutine: 
6C illustrates the "Pay Mortgage Bill" subrou- 
tine: 

25 6D illustrates the "Withdraw Other Amount" 

subroutine: 

6E illustrates the "Return Card* subroutine; and 
6F illustrates a function group. 

30 Throughout the figures, the same reference numer- 
als and characters, unless otherwise stated, are used 
to denote like features, elements, components or por- 
tions of the illustrated embodiment. Moreover while the 
subject invention will now be described in detail with ref- 

35 erence to the figures, it is done so in connection with a 
preferred embodiment. It is intended that changes and 
modifications can be made to the described embodi- 
ment without departing from the true scope of the sub- 
ject invention as defined by the appended claims. 

-to Fig. 1 depicts the external portion of a financial 
transaction terminal 101 which can be used in a con- 
ventional manner. While the transaction terminal de- 
scribed is an ATM machine, the invention is not limited 
to this one type of terminal, but is inclusive of home com- 

45 puters, POS terminals, and pay telephones and other 
devices that accept financial cards. Any other type of 
terminal that accepts financial cards for processing is 
also included. 

Terminal 101 comprises a display 103, selector but- 

50 tons 105, key pad 107. card receptacle 109 and money 
receptacle 111. A transaction performed in a conven- 
tional manner using terminal 101 will now be described. 
When a financial transaction card is inserted into card 
receptacle 109 by a customer, display 103 is activated 

55 to display a menu of functions which can be selected by 
the customer. The customer then activates one of se- 
lection buttons 105 to choose a desired function. The 
customer can make further data entries as needed by 
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pressing a number on key board 1 09 or be selecting fur- 
ther selection buttons 105. Cash can be deposited or 
withdrawn from a customer's account by placing or re- 
ceiving money in money receptacle 111. 

The images and menu features shown on display 5 
103 varies by financial institution and actual terminal. 
While most ATM terminals have the basic operations of 
withdrawing and depositing money, other features can 
be included depending upon the actual terminal and 
system operating. w 

Fig. 2 depicts a menu screen which is an example 
of a screen a customer would encounter during a trans- 
action when used in a conventional manner. This par- 
ticular screen might appear after the function "Withdraw 
Cash" is chosen. Figure 2 shows display 103 with func- is 
tion choices 201 displayed as "From Checking", "From 
Savings", or "Cancel". This is one window from a layered 
display menu that may be found in a terminal where the 
screen display is dependent upon the customer's last 
entry. The actual display will vary terminal by terminal 20 
and the word choice and available options will differ. 

The sophistication of display will also vary by type 
of terminal. A home computer terminal with card reader 
will have a high resolution display while a pay-phone 
may have only a limited character display. 2$ 

Fig. 3 is a schematic diagram of the internal elec- 
tronics present in the financial transaction terminal 101 
in accordance with the present invention. Terminal 101 
comprises a microprocessor 301 : a memory 303 and in- 
teraction panel 305. The microprocessor is connected 30 
to the memory 303 which stores an operating system 
which orchestrates the operation of terminal 101 . Mem- 
ory 303 also stores a conventional interpreter to process 
the transaction instruction steps. Unlike the prior art. the 
instruction steps are stored in and read from a custom- 
ized financial card, described below. The interpreter is 
stored in a part of the memory 303 which is designated 
350 in Figure 3. It translates the read instructions into 
machine code for use in execution of one or more finan- 
cial transactions. 40 

Microprocessor 301 is connected to interaction 
panel 305 via connectors 309. Interaction panel 305 
comprises display 103 a display controller, function but- 
tons 105, key pad 107 and receptacles 109 and 111. 
When a financial transaction is initiated by a customer *$ 
in a conventional manner by placing his financial card 
into receptacle 109, the transaction program in the card 
is interpreted by the interpreter and executed by micro- 
processor 301 which in turn generates displays, re- 
trieves data, performs calculations, and does other com- so 
puling functions necessary for a successful and com- 
plete financial transaction. In this manner, unlike the pri- 
or art. the transaction instruction steps may differ for 
each card placed in the terminal. 

Fig. 4 illustrates a customized program card 400, in $$ 
accordance with the invention, that is used with terminal 
101. The customized program card 400 comprises a 
memory 401, an Input/Output (I/O) port 407 and leads 
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409 to connect the I/O port 407 to memory 401 . Memory 
40 1 comprises a program memory space 403 and a data 
memory space 405. Program memory space 403 is 
used to store the programming instruction sets which 
are associated with, i.e., perform when interpreted and 
executed, one or more financial transactions. Routines 
may also be present to instruct the terminal regarding 
the options available to the user. These options are pre- 
selected by the user or card issuer, meaning that the 
instructions associated with these options are placed on 
the card prior to use for a particular financial transaction. 

The contents of program memory 403 can be re- 
trieved by an outside source or altered (updated, added 
to. or reduced) via the I/O port 407. This allows for mod- 
ification of the financial transactions available to, or dis- 
play features provided to, the user. 

Data memory space 405 contains stored data nec- 
essary to complete a financial transaction. Stored data 
may include the card holder's name, account number, 
card expiration date, security code and preference indi- 
cators. The data may also include personalized spend- 
ing limits set by the card issuing financial institution. Oth- 
er categories of data may also be stored that can be 
used during a transaction. Card 400 can also include a 
microprocessor and be an integrated chip "IC" card that 
can perform its own processor operation such as a high 
level security check of the validity of the card. 

In accordance with the invention, card 400 can be 
used as a combination bank card, credit card and/or 
debit card, and/or purse card or the like. The card 400 
can contain sufficient instructions and data to support 
bank operations, credit card operations and other finan- 
cial transactions. Card 400 can be used with a variety 
of terminal types. 

A typical transaction using the techniques of the 
present invention will now be described. The card holder 
first places card 400 into the terminal receptacle 109 to 
begin a financial transaction. Terminal 101 then identi- 
fies card 400 as a customized programming card pref- 
erably by reading some initial data code stored in data 
memory 405 of card 400, which data is indicative of a 
card containing operating instructions to be read by the 
terminal. 

Terminal 101 next preferably reads the program- 
ming steps from programming memory 403 into a termi- 
nal memory 350. The programming steps reflect those 
pre-selected features desired by the customer. Alterna- 
tively, the terminal initially only re^ds those instructions 
necessarily to generate a display of a specialized mes- 
sage or the options available to the user. In this example, 
however, the terminal reads all of the instructions stored 
in memory 403. 

The instruction steps read by the terminal are then 
processed, i.e., interpreted, by a terminal resident inter- 
preter stored in terminal memory 303, to make the steps 
executable by the terminal. The terminal then executes 
the interpreted instructions to conduct one or more of 
the financial transactions. 
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Preferably, instructions from the card are read by 
the terminal which indicate the options available to the 
user. These options are displayed to the user who se- 
lects one of the financial transactions to be performed. 
The terminal preferably then reads and interprets the in- 5 
structions associated with the selected option and exe- 
cutes the interpreted instructions to complete the select- 
ed transaction. After the transaction is complete : termi- 
nal 101 preferably automatically erases the customized 
program that was just run and resets for the next trans- 
action. 

Figure 5 depicts a customized display screen using 
the present invention. The display screen shows text 
blocks identifying available functions that are personal- 
ized to the card user. The stored program on each cus- 
tomer's cards allows the display and interaction of every 
terminal performing a transaction to be customized to 
the needs of each individual customer. For example, text 
box 501 displays a welcome message by name to the 
card user. Text block 515 displays a pleasant picture or 
a quote for the day to make transactions more enjoyable 
to customers. These extra features can be available de- 
pending on the desires of the particular customer, and/or 
issuer The actual features described are only examples 
of the vast potential of items displayed on the screen. 

The function displays can be tailored to the desired 
choices of the customer by storing in the card only op- 
erating instructions for those functions chosen. A cur- 
rent popular function in financial transactions is the 
"Quick Cash" key which will retrieve a predetermined 
amount (e.g.. $100) from the customer's checking ac- 
count with the depression of a selected button. Howev- 
er in the prior art. the predetermined amount is set by 
the program stored in the terminal and cannot be 
changed for each customer While different amounts of 
memory for a particular withdrawal can be selected, it 
requires many additional key strokes and takes a longer 
time to complete the transaction. With the customized 
financial transaction card 400 ; the "Quick Cash" function 
can be set to any desired level, (e g $20. $50 etc.), which 
would speed up transactions considerably if a customer 
normally retrieves the same amount each time, some- 
thing that most customers do. In this particular instance, 
the user's desired "Quick Cash" function is $75 as re- 
flected by function block 505. 

Function block 507 is a normal "Withdraw Specified 
Amount" function which is a necessary feature in case 
the customer desires to withdraw a different amount 
than the predetermined "Quick Cash" amount. The 
present invention also allows the card issuing financial 
institution to limit withdrawal amounts of a customer de- 
pending on past credit history and risk, and perhaps re- 
quiring authorization by the bank if the requested with- 
drawal exceeds a certain limit. This is accomplished by 
storing the correct combination of instruction sets on the 
card. 

Function key 509 is a bill paying function key. This 
function, while currently not available at most financial 



transaction terminals, could be added. The function key 
would allow a card holder to transfer a designated 
amount of funds to a service provider, i.e., a telephone 
company or mortgage lender, without writing a check. 
The amount could be for a current level of a bill such as 
a mortgage payment whose value would be stored in 
the data memory 405 of card 400. This function would 
be available to customers if they desired it. However, 
not every customer would want to have this option avail- 
able Some customers may prefer to pay their bills di- 
rectly. The bill paying function is good example of a func- 
tion that can be added for only those customers who 
desire it. If a customer wishes to have this option, his or 
her respective customized financial card 400 would be 
altered accordingly and contain the necessary instruc- 
tions to be read, interpreted and executed. 

Function 511 represents an option to order mer- 
chandise from catalogs while simultaneously transfer- 
ring money from a customer's checking account to the 
catalog company. Pressing the button corresponding to 
catalog shopping function will bring up a new set of 
menu choices to complete the purchase. For example, 
terminal 101 can display only the preselected catalog 
companies previously chosen by the customer to make 
a purchase by storing the correct programming steps 
and corresponding data in card 400. This would allow 
only the customer's favorite catalogs to appear on the 
screen. Catalog ordering is another function that would 
be desired by some customers and not by others. If the 
function is preferred, the corresponding programming 
instructions will be added to the operating code stored 
in the customized financial card 400 of each user. 

Other potential functions include buying lottery tick- 
ets 513. This is one more example of the many possible 
functions that can be stored as part of the customized 
program on each card user's card. By allowing the cus- 
tomer to customize the transaction menus to his prefer- 
ences, the financial transactions become much more ef- 
ficient and user friendly thus increasing the use of the 
cards 400. 

Specialized functions by financial institution or ven- 
dor are well suited to be used with this invention. Bonus 
programs for financial transactions such as frequent fly- 
er, frequent purchaser, or rebate programs are only 
used by customers who desire to be part of the pro- 
grams. The corresponding instruction steps for each 
program need only be stored on the participants card 
400. and not resident on all transaction terminals. 

Some functions will be limited to a certain type of 
terminal for a particular transaction. A "Withdraw Cash" 
function cannot be performed at a pay telephone. The 
interpreter programs stored in each terminal will only al- 
low the functions which can be run on its particular ter- 
minal to be executed. Alternatively, the terminal will only 
retrieve usable instruction steps from card 400 that are 
capable of being performed. 

Preferred functions can be added to each custom- 
er's customized financial card 400 easily. Special termi- 
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nals can be located at central locations such as bank 
branches that will have the ability to transmit instruction 
sets for a particular function to each financial card 400. 
The instruction sets can be designed as subroutines 
which can be called from a main program when that par- 
ticular function is selected. 

Moreover, these specialized terminals can afso re- 
move functions when a customer and/or issuer no long- 
er desires the particular function. This can be accom- 
plished by removing the corresponding instruction set 
or by simply disabling the operating program from exe- 
cuting that subroutine. Alternatively, the financial insti- 
tution issuing financial card 400 can issue a new card 
with the correct operating instructions present to match 
the customer's desired features. An initial questionnaire 
can be filled out by a new customer to select his desig- 
nated features. A card can be equipped with proper rou- 
tines corresponding to the selected functions. 

Figs. 6A-F are an example of the structure of the 
transaction program comprised of programming instruc- 
tions which is stored in memory 403 of customized fi- 
nancial card 400. The program which serves as an ex- 
ample consists structurally of a core program 690 (Fig. 
6A) and four subroutines 692 (Fig. 6B), 694 (Fig. 6C), 
696 (Fig. 6D) and 698 (Fig. 6E). Also part of the program 
set is group 699 (Fig. 6F) which contains instructions 
used for customizing the display menus. 

The construction of a typical transaction program of 
the present invention to be stored in card 400 and exe- 
cuted on terminal 101 after card 400 is inserted into ter- 
minal 101 will now be described. The instruction set 
shown is written for an ATM terminal, and the instruc- 
tions would be altered according to the limitations of the 
actual terminal used. e.g. less sophisticated for pay 
phones The example instructions show the unique level 
of interaction between the card 400 and terminal 101 
controlled by the contents of the card's memory 403. 

The core program 690 shown in Fig. 6A includes a 
set of instructions to retrieve customer related data 
stored in card 400. display the available optional trans- 
action functions to the customer, accept the customer's 
selection of a desired function, and finally execute the 
proper subroutine containing further instructions corre- 
sponding to the customer's selection. For the example 
shown, instruction 601 retrieves data representing the 
customer's name and account number from the memory 
of card 400 and places the data temporarily in the ter- 
minal memory. The command "CGET" retrieves speci- 
fied data from customized financial card 400. Instruction 
603 displays a predefined message welcoming the cus- 
tomer and displays his transaction options. The prede- 
fined message can either be stored in card 400 or in 
terminal 101. The data element called "name#* re- 
trieved from card 400 is displayed as part of the mes- 
sage. The command "Display message 1 " also retrieves 
from group 699 stored in memory space 403 the titles 
of the functions which have been pre-selected by the 
customer causing corresponding instructions for those 



functions to be stored in card 400. If a new function not 
previously stored on card 400 is desired by a customer 
and then added to card 400 by storing an additional set 
of instructions for that function, then the corresponding 

5 function titles are also added to group 699 stored in card 
400. This enables the available selected functions cho- 
sen by the individual customer to be displayed by termi- 
nal 101 after the card 400 is inserted into terminal 101 . 
Next, instruction 605 retrieves input data from ter- 

10 minal 101 which corresponds to the selection made by 
the customer by pressing one of function keys 105 on 
terminal 101. Instruction 607 then executes the inter- 
preted instructions in the selected subroutine which cor- 
responds to the customer's selection. For example, if 

'5 the customer pressed the top button on the display of 
terminal 101 , the subroutine corresponding to that func- 
tion would be executed: if the customer chose a different 
button corresponding to another selection, the corre- 
sponding subroutine would be executed, etc. When a 
20 new function is added to the operating program stored 
in customer's card 400 : the name of the subroutine is 
added to instruction 607 along with the new instruction 
set for that subroutine so that the new subroutine to be 
executed. 

2$ Subroutine 692 shown in Fig. 6B contains instruc- 
tions to implement the "Quick Cash" function. Instruction 
609 is a title instruction identifying the memory location 
of the "Quick Cash" subroutine. Instruction 611 retrieves 
data stored in card 400 indicating the amount the cus- 

30 tomer desires to receive when selecting "Quick Cash". 
The stored data is previously designated by the custom- 
er and is customized for each customer. The amount, 
designated by the variable "Qamountr. can be 
changed by the customer at terminal 101 if an additional 

35 feature of "change Quick cash amount" (instruction set 
not shown) is selected. That function would rewrite the 
actual data corresponding the Qamount value stored in 
customer's card 400. The data element Qamounttf be- 
ing stored in the customer's card 400 allows the custom- 

•*o er to designate the same Quick cash value for all his 
transactions, whether that amount be $1 0, $50 or $1 00. 
Current financial terminals do not allow that flexibility. 

Instruction 613 electronically withdraws the money 
from the customer's account by communicating the 

45 transaction with the customer's bank or a clearing 
house. The "Withdraw" command uses retrieve data 
variables account# and Qamount# to complete the in- 
struction. Instruction 61 5 instructs-terminal 101 to phys- 
ically give funds in the amount designated by 

so "Qamount#" from terminal 101 to the customer. Finally, 
instruction 639 returns the execution of the program to 
core routine 690. 

Subroutine 694 shown in Fig. 6C contains instruc- 
tions to implement the "Pay Mortgage Bill" function 

55 when selected. Instruction 619 is the title instruction 
identifying the memory location of the "Pay Mortgage 
Bill" subroutine. Instruction 621 retrieves data stored on 
card 400 corresponding to the customer's mortgage 
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identification number and his/her mortgage payment 
amount. Instruction 623 electronically withdraws the 
mortgage payment amount from an account identified 
by the already retrieved customer's account number. In- 
struction 625 electronically transfers funds in the 
amount of the mortgage payment variable to the proper 
lender account identified with the customer's mortgage 
identification number. These data variables are stored 
on the customer's financial card 400. This allows the 
customer to pay the monthly mortgage payment with 
one touch of a button. Instruction 627 then returns the 
execution of the program to core program 690. The com- 
bination of stored data variables and the selected oper- 
ating instructions on card 400 allows for a transaction to 
take place that is uniquely tailored for each identified 
customer. 

Subroutine 696 shown in Fig. 6D contains instruc- 
tion statements to implement the "Withdraw Other 
Amount" function. Instruction 629 is a title instruction 
identifying the memory location of the "Withdraw Other 
Amount" subroutine. Instruction 631 displays a second 
pre-constructed message stored in either card 400 or 
terminal 1 0 1 to display to the customer who initiated the 
translation that a desired amount of withdrawal must be 
chosen. Instruction 633 accepts the consumer's selec- 
tion which is made by punching keys from keypad 107 
and further stores the selected amount in the variable 
"amount#" in terminal 1 01 An example of a value stored 
in amounts is $35.00. Instruction 635 withdraws funds 
of the value stored in amounts from the customer's ac- 
count designated by the retrieved variable accounts. In- 
struction 637 then directs terminal 101 to physically give 
cash equal to the value stored in amounts to the cus- 
tomer. Instruction 639 then returns the execution of the 
transaction program to core program 690 because the 
execution of the "Withdraw Other Amount" function is 
complete. 

Subroutine 698 shown in Fig. 6E contains instruc- 
tions to implement the "Return card" function. This sub- 
routine is executed at the end of the financial transaction 
when terminal 101 is directed to return the customer's 
financial card 400. Instruction 641 is a title instruction 
identifying the memory location of the "Return card" sub- 
routine. Instruction 631 transfers data that has been al- 
tered during the transaction from terminal 101 to card 
400 that has not been previously updated in card 400. 
This updated data can include transaction identification 
information, new preferred customer information or oth- 
er variables. It allows the data stored in card 400 to re- 
flect the customer's most recent preferences. Instruc- 
tion 645 directs terminal 1 01 to eject the customer's card 
400 because the transaction is complete. Instruction 
647 is an "End" instruction and directs the terminal to 
reset and wait for the next customer. The terminal then 
removes the transaction instructions from its temporary 
memory which had been copied from card 400. This cre- 
ates space in memory for the next transaction program 
corresponding to the next customer's financial card 400. 



Group 699 shown in Fig. 6F is a group of elements 
which store the titles of the available functions that have 
been selected by the customer to be in his or her reper- 
toire of possible transactions. The block can be easily 

5 altered and updated depending on the selections of 
functions for each particular customer. Element 651 is 
the name of the function "Quick Cash". Element 653 
contains the name of the function "Pay Mortgage Bill". 
Element 655 contains the name of the function "With- 

io draw Other Amount". Element 657 contains the name 
of the function "Return Card". Element 659 is shown 
without characters but can be assigned a function title 
if the customer adds a new function to his card 400. 
The instruction set illustrated in Fig. 6 does not limit 

'5 the invention to only using those instructions. The in- 
structions shown are simply illustrative of the type of 
commands that instruct terminal operation. Moreover, 
terminal 101 could execute each individual instruction 
stored in memory space 403 one at a time instead of 

20 reading the entire program into a memory buffer in ter- 
minal 101 . This may provide an advantage in execution 
time and save terminal memory space depending on the 
amount of instructions that must be executed. 

In addition, the operating instruction set could be 

25 transferred from card 400 to terminal 101 in a different 
mode than inserting the card 400 into the terminal. Card 
400 could be scanned without physical contact to termi- 
nal 101 to transmit information. Card memory 401 could 
also comprise a magnetic strip capable of storing a large 

30 quantity of code and/or data. 

The foregoing merely illustrates the principles of the 
invention. It will thus be appreciated that those skilled in 
the art will be able to devise numerous systems and 
methods which, although not explicitly shown or de- 
scribed herein, embody the principles of the invention 
and are thus fall within the scope of the invention, as 
claimed. 

-to Claims 

1. A financial card system for conducting financial 
transactions comprising: 

45 at least one financial card (400) including 

means (403) for storing pre-selected instruc- 
tions (690: 692; 694: 696: 698: 699): and 
a plurality of terminals (101 ) each including 
means for reading one t>r more of the pre-se- 

so lected instructions stored in the card, means 

(303) for interpreting the read pre-selected in- 
structions, and means (301) responsive to the 
interpreted instructions for conducting at least 
one of the financial transactions. 

55 

2. A system as claimed in claim 1 . wherein the card 
further includes means (690) for indicating the pres- 
ence of the pre-selected instructions and wherein 
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the reading means are responsive to the indicating 
means to read one or more of the pre-selected in- 
structions. 

A system as claimed in claim 1 or 2. wherein the $ 
pre-selected instructions includes one or more sets 
of instructions (692: 694; 696) corresponding re- 
spectively to one or more of the financial transac- 
tions. 

w 

A system as claimed in claim 3 wherein each of the 
terminals further includes means (305: 505: 507: 
509: 511: 513: 515: 699) for selecting at least one 
of the financial transactions, wherein the financial 
transaction conducted is the one selected. is 

A system as claimed in claim 4 wherein the reading 
means is responsive to the selecting means for 
reading the set of instructions corresponding to the 
selected financial transaction. 20 

A system as claimed in claim 4 or 5 wherein the in- 
terpreting means is responsive to the selecting 
means for interpreting the set of instructions corre- 
sponding to the selected financial transaction. 25 

A system as claimed in claim 4. 5 or 6, wherein the 
means for selecting includes display means (505; 
507; 509: 511; 513: 515) responsive to the reading 
means for displaying the financial transactions 30 
available for selection 

A system as claimed in claim 4. 5 : 6 or 7. wherein 
the financial card further includes data means (405) 
for storing data associated with a user of the card, is 
and wherein the means for conducting the selected 
financial transaction is responsive to the selecting 
means and the data means 

A system as claimed in claim 8 ; wherein each of the <*o 
terminals further includes storage means (350) for 
temporarily storing one or more of the pre-selected 
instructions. 

A system as claimed in claim 9 wherein the system ^5 
further comprises means (699) for adding to and 
means for deleting from the financial card one or 
more of the pre-selected instructions. 

A method of conducting financial transactions with so 
a financial card (400), comprising the steps of: 

storing in the financial card pre-selected in- 
structions (690. 692: 694: 696: 698; 699) asso- 
ciated with one or more financial transactions; ss 
reading the pre-selected instructions stored in 
the card, interpreting the read pre-selected in- 
structions, and executing the interpreted in- 



structions to conduct one or more of the finan- 
cial transactions 

12. A method as claimed in claim 11 wherein the read- 
ing, interpreting and executing steps are performa- 
ble in each of a plurality of terminals. 

13. A method as claimed in claim 12, further including 
the steps of selecting at least one of the financial 
transactions at one of the terminals and conducting 
the selected financial transaction. 

1 4. A method as claimed in claim 1 3, wherein the stor- 
ing step further includes storing data in the card, 
which data is used in conducting the one or more 
financial transactions. 



8 



EP 0 717 381 A1 




FIG. 1 



9 



EP 0 717 381 A1 



103" 



FROM 
CHECKING 



4- 



•201 



FROM 
SAVINGS 



CANCEL 



FIG. 2 



101 



INTERACTION PANEL 



305 

i 



-309 



MICRO- 
PROCESSOR 



MEMORY 



-301 



303 



-350 



FIG. 3 



10 



EP 0 717 381 A1 




400 



FIG. 4 



407 



501 



HELLO 
PAMELA 



Quote For the Day 



WITHDRAW 
$75 



1 WITHDRAW 
ANY $ 



PAY PHONE 
BILL 



CATALOG SHOP- 



515 



BUY LOTTERY 
TICKET 



-503 
•505 
507 

509 
-511 
■513 



FIG. 5 



11 



EP 0 717 381 A1 



CGET NAME#, ACCOUNT# 



•601 



DISPLAY MESSAGE 1, NAME# 



•603 



690< 




ON INPUT#, GOTO *QC, *PM, *0C, *RC 



607 



FIG. 6A 



: QC SUBROUTINE QUICK CASH 



609 




CGET OAMOUNT# 




611 



692 < [ WITHDRAWN ACCOUNT#, QAMOUNT# 



Z^-613 



GIVE QAMOUNT# 




615 



RETURN 617 




FIG. 6B 



12 



EP 0 717 381 A1 



694 < 



*PM SUBROUTINE- PAY MORTGAGE 



-619 



CGET MORT#, MACCOUNT# 



-621 



WITHDRAW ACCOUNT*, MORT# 



623 



PAY MACCOUNT*, MORT# 




-625 



627 



FIG. 6C 



696< 



*OC SUBROUTINE 
WITHDRAW OTHER CASH 



629 




DISPLAY MESSAGE 2 



GIVE AMOUNT# 



-631 



-633 



WITHDRAW ACCOUNT#, AMOUNT* 



-635 



^ GET AMOUNT* L--637 - 



^ RETURN 



639 



FIG. 6D 



13 



EP0 717 381 A1 



*RC SUBROUTINE 
RETURN CARD 



TRANSFER NEW DATA 



698 < 




-641 



643 



645 



FUNCTIONI =QUICKCASH 




FUNCTION2 = PAY MORTGAGE 




651 



653 



699<; (FUNCTION3 = WITHDRAW ANY AMOUNT V— 655 




FUNCTI0N4 = 


RETURN CARD 






\ FUNCTIONS = EMPTY / 


FIG. 


6F 



657 



-659 



14 



EP0 717 381 A1 



Kurupcu/i Patent 
Office 



EUROPEAN SEARCH REPORT 



Application (S umber 

EP 95 30 5363 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPI.ICA HON <lnt.CL6) 



Y 
A 
Y 
A 

P.A 

A 
A 
A 



EP-A-0 446 081 (GEMPLUS CARD 
INTERNATIONAL) 

* the whole document * 

EP-A-0 159 651 (0MR0N TATEISI ELECTRONICS) 

* abstract; claims; figures * 

* page 5, line 1 - page 11, line 2 * 

EP-A-0 662 674 (FRANCE TELECOM) 

* abstract; claims; figures * 

EP-A-0 157 416 (0MR0N TATEISI ELECTRONICS) 

EP-A-0 368 752 (BULL CP8) 

WO-A-94 10657 (INTELLECT AUSTRALIA) 



1,3-5, 

8-14 

6 

1,3-5, 

8-14 

2,7 



1,2,7, 
11-14 



G07F7/10 



TECHNICAL FIELDS 
SEARCH*'.!) llnt.Cl.6) 



G07F 
G06K 



The present search report has been drawn up for all claims 



Place mt tcttch 

THE HAGUE 



22 November 1995 



David, J 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant ii taken alone 

Y : particularly relevant if combined with another 

document of the tame category 
A : technological background 
O : non-wrtttcn disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, or 

after the filing date 
U : document cited in the application 
I, : document cited for other reasons 



& : member ol the same patent faintly, corresponding 
document 



15 



